Generally, the present application relates to managing access to resources. More specifically, the application is related to techniques to change (e.g., reduce or lower) an authentication level of a session providing access to resources.
Modern businesses rely on a variety of protected resources (e.g., applications and systems that control and generate information) critical to business operations. Different applications often provide different services and information, and different users may require access to different levels of information within each system or application. As such, the level of access that users are granted to a protected resource may depend on a role of the user. For example, a manager may need access to certain information about employees that report to him, but it may be improper for that manager to access the same information about those whom he reports to.
Earlier less sophisticated applications incorporated access management business logic directly into the application code. That is to say, each application would require users to have a separate account, separate policy logic, and separate permissions, for example. Furthermore, when a user is authenticated by one of these applications, this authentication remains unknown to other applications in the enterprise because the fact that authentication with the first application has taken place is not shared. Thus, there is no concept of trust between applications using different systems for authentication and access control. Engineers quickly realized that having an access management system for each application in an enterprise was much like having a gas station for each car, and determined that authentication and access control would be more efficiently implemented and managed as a shared resource. These shared resources became known as an access management systems.
Access management systems often use policies and other business logic to make a determination regarding whether a particular access request should be granted to a particular protected resource. Upon making a determination that access should be granted, a token is provided to the requestor. This token is like a key that can be used to open a door that guards restricted data. For example, a user may attempt to access a human resources database to gather information about certain employees such as salary information. The user's web browser makes a request to the application, which requires authentication. If the web browser does not have a token, the user is asked to log in to the access management system. When the user is authenticated, the user's browser receives a cookie that represents a token that may be used to access the human resources application.
In an enterprise, users (e.g., employees) typically may have access to one or more protected resources. A protected resource may utilize different access control policies and require different credentials (e.g., user names and passwords). A single sign-on session (SSO) system can provide a user with an authentication session enabling access to multiple protected resources after an initial, single authentication of a user. For example, when the user logs-in to their work computer, the user can then also have access to one or more other protected resources. An access management system may challenge a user to verify the user's identity to determine access to a resource. The user may be challenged for information based on a combination of “what you have,” “what you know,” and “who you are.” The user may continue to access protected resources so long as the user successfully responds to the challenge, thereby maintaining a valid session for an SSO system.
Access management systems may employ various one or more authentication schemes to authenticate a user for access to a protected resource. An authentication scheme may implement an authentication mechanism to authenticate a user. Access to a protected resource may be controlled by one or more authentication schemes that are defined based on an authentication level for access to the protected resource. Access to some protected resources may be protected using multiple authentication schemes. For example, varying authentication levels may be defined for access to multiple protected resources. In some embodiments, one authentication level may enable a user to access protected resources defined for that authentication level and for resources defined for any authentication level lower that that authentication level, if one exists. Each authentication level may be associated with one or more authentication schemes. An authentication level may be determined based on the authentication schemes that have been applied. When a user is validated based on an authentication scheme, the user may be provided with an authentication session (e.g., an SSO authentication session) for the authentication level determined based on the authentication scheme.
Protected resources are configured to be accessed by a user that is provided with an authentication session based on an authentication level for accessing those protected resources. As such, a user must have an authentication session of a minimum authentication level for a protected resource for which the user is authenticated to access. When the authentication level is defined for multiple protected resources, a user may be automatically granted with access to those protected resources upon authentication of the user to access one of those protected resources at the authentication level. When a user accesses a protected resource defined by a higher authentication level, the access management system may challenge the user for extra credentials determined by the authentication scheme(s) defined for the higher authentication level. Upon validation of the user for a higher authentication level, the authentication session of the user may be increased (e.g., “stepped up”) to gain access to the protected resourced at the higher authentication level. One or more other protected resources may be accessible at the higher authentication level. As such, the user can access the other protected resources at the higher level for the authentication session or any level lower than the higher authentication level.
Once the authentication session is adjusted to enable a user to access the higher authentication level, an access management system may provide a user with access to several protected resources at the higher authentication level. Access at the higher authentication level may be provided for the authentication session regardless of whether the user intends to access all of the protected resources at the higher authentication level. Access to all protected resources for the authentication session at the higher authentication level may pose a security threat for access to the protected resource. For example, any user that gains access to a client device having an authentication session at a higher authentication level may access all resources accessible at the higher authentication level. Such a scenario can happen in environment where a client device is public or shared by many users. For example, when a client device is left unattended, any user with access to the client device can then gain access resources at a higher level if the authentication session remains valid on the client device. To reduce these vulnerabilities with an authentication session at a higher authentication level, some have attempted to configure or modify access management systems to change the settings (e.g., timeout) of the authentication session to force a user to re-authenticate for the authentication session. Access management solutions may be challenged to provide users with the ability to adjust an authentication level such that it is reduced or lowered for an authentication session to limit access to less than what it was previously.